QuickSightユーザーをプロビジョニング時のイベントは手動ユーザー登録とSSOで発生イベントが違うという話

いわさ

2022.03.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

QuickSight上でのユーザー作成イベントを検知するためにEventBridgeでパターンを設定していたのですが、外部IdPによるシングルサインオン(SSO)を使った場合にうまく動作しませんでした。
結論としては登録パターンによって発生するイベントが全然違っていたということなのですが、QuickSightのユーザー登録からEventBridgeを利用するパターンの参考になるかなと思い、記事にしておきます。

最初設定していたイベントパターン

QuickSightでユーザー登録を行うにはRegisterUserを使います。
そこで当初は以下のようにイベントパターンを指定していました。

{
  "source": ["aws.quicksight"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["quicksight.amazonaws.com"],
    "eventName": ["RegisterUser"]
  }
}

ところが、以下のような構成で外部IDプロバイダーからSSOで新規ユーザーをプロビジョニングさせるとこのイベントが発生していませんでした。

原因

通常のユーザー登録とSSOでのプロビジョニング時でデータイベントが全然違っていたことが原因でした。

{
    "version": "0",
    "id": "66e4d212-85bf-c002-a345-3867a184465d",
    "detail-type": "AWS API Call via CloudTrail",
    "source": "aws.quicksight",
    "account": "123456789012",
    "detail": {
        "eventSource": "http://quicksight.amazonaws.com",
        "eventName": "RegisterUser",
        "userAgent": "aws-cli/2.4.23 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off command/quicksight.register-user",
        "requestParameters": {
            "identityType": "QUICKSIGHT",
            "email": "[email protected]",
            "userRole": "READER",
            "awsAccountId": "123456789012",
            "namespace": "default",
            "userName": "cli1"
        },
        "responseElements": {
            "user": {
                "arn": "arn:aws:quicksight:ap-northeast-1:123456789012:user/default/cli1",
                "userName": "cli1",
                "email": "[email protected]",
                "role": "READER",
                "identityType": "QUICKSIGHT",
                "active": false,
                "principalId": "user/d-95671d86a5/8c187c18-1329-4357-a8a8-ba51bbb08b90"
            },
            "userInvitationUrl": "https://ap-northeast-1.signin.aws.amazon.com/inviteuser?hogehoge",
        },
        "eventType": "AwsApiCall",
        "managementEvent": true,
        "eventCategory": "Management"
    }
}

{
    "version": "0",
    "id": "7166a78d-181e-bffc-6707-a97a0c99e5e3",
    "detail-type": "AWS Service Event via CloudTrail",
    "source": "aws.quicksight",
    "detail": {
        "eventVersion": "1.08",
        "eventSource": "http://quicksight.amazonaws.com",
        "eventName": "CreateUser",
        "eventType": "AwsServiceEvent",
        "managementEvent": true,
        "serviceEventDetails": {
            "eventRequestDetails": {
                "role": "READER",
                "userName": "trustlogin-reader2:[email protected]"
            },
            "eventResponseDetails": {
                "userId": "arn:aws:sts::123456789012:assumed-role/trustlogin-reader2/[email protected]"
            }
        },
        "eventCategory": "Management"
    }
}

SSOでのプロビジョニング時はAWS Service EventによるCreateUserが発生していました。

SSOプロビジョニングユーザーを拾うイベントパターン

以上から、SSOプロビジョニングイベントのイベントパターンは以下のようになります。

{
  "source": ["aws.quicksight"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventSource": ["quicksight.amazonaws.com"],
    "eventName": ["CreateUser"]
  }
}

また、後続のLambdaやStep Functionsなどで処理する場合のユーザー名取得元などもRegisterUserとは構成が異なるので注意が必要です。